An application running on an operating system in a host computer generally prints using the graphics engine of the operating system and the printer driver of a destination printer. First, the application to print creates print setting information suited to the printer performance through inquiry to the printer driver. Then, the application creates graphics data based on the created print setting information, and passes it to the graphics engine. The graphics engine creates print data interpretable by the printer in cooperation with the printer driver.
Data temporarily created at this time is called a spool file. The spool file is finally formed from a set of command language data to control the printer, and is passed to a spooler. The spooler manages the spool file in a so-called “queue” so as to print even a plurality of spool files sequentially by the printer. When the printer becomes printable, the spooler sequentially reads out spool files from the queue and transmits them to the printer to print.
The graphics engine is a system which allows an application to obtain the same output result only by uniquely generating an image, regardless of hardware such as the display type, video card, printer type, or printer control language. In general, the graphics engine is provided as part of the operating system. The graphics engine is also known as an engine to implement an environment WYSIWYG (“What You See Is What You Get”). The number of graphics engines is not always one on the operating system, but may be two or more.
For example, a Microsoft Windows® operating system supports two graphics engines GDI (Graphics Device Interface) and DirectX Graphics. The conventional GDI is competent to process data which is processed by business applications such as a word processing application or spreadsheet application. To the contrary, the DirectX Graphics exists as a graphics engine which maximizes the performance of a hardware device for the real-time graphics processes of a game, multimedia title, and the like. An application can adaptively exploit these two graphics engines. However, the DirectX Graphics is a display graphics engine, and the GDI has been used as a print graphics engine for a long time.
For example, Microsoft held a hardware engineering conference WinHEC 2005 in Seattle, U.S.A., in 2005. At this conference, Microsoft announced that the latest Microsoft OS “Windows® Vista” adds a new graphics engine “WPF” (Microsoft Corporation, [Advances in Windows® Printing: TWPRO5001_WinHEC05.ppt], [online], May 7, 2004, [searched on Feb. 28, 2005], Internet, the website at microsoft.com in the subdirectory default.mspx in the subdirectory print in the subdirectory device in the subdirectory whdc). The WPF also newly adds print processes, and can adopt a new printing system in addition to printing using the conventional GDI (XPS and Color Printing Enhancements in Microsoft Windows® Vista (the website at microsoft.com in the subdirectory vista_print.mspx in the subdirectory xps in the subdirectory whdc). The WPF stands for Windows® Presentation Foundation.
A printing system inherited from a conventional Windows® utilizes a spool file “EMF” via the GDI from an application using an API called a Win32API, and creates print data by a printer driver for the GDI.
The API stands for Application Programming Interface. An application using the Win32API will be referred to as a Win32 application. The EMF stands for Enhanced Metafile. A printer driver for the GDI will be referred to as a GDI printer driver.
A printing system to print from the Win32 application via the GDI printer driver is called a GDI print path. A printing system using the WPF is called an XPS (XML Paper Specification) print path. The XPS print path is a system which creates print data by a printer driver for the WPF using a spool file “XPS” via the WPF from an application using an API called a WinFXAPI.
An application using the WinFXAPI will be referred to as a WPF application. The printer driver for the WPF will be referred to as an XPSDrv printer driver.
The use of the XPS print path instead of the conventional GDI print path has many merits such as a more advanced color process, and easy extension and high compatibility depending on the print settings of the XML formats of the XPS spool file and markup language with open specifications.
The XML stands for eXtensible Markup Language.
The GDI and XPSDrv printer drivers have different attributes. An application regards printer drivers for even the same printer as different printers. The application can use an API to determine whether the printer driver is a GDI or XPSDrv one. This API is newly added, so a conventional Win32 application cannot make any determination when printing. The user can select either driver, but it is difficult to explicitly determine whether the application is a Win32 or WPF one or whether the printer driver is a GDI or XPSDrv one. It is, therefore, difficult to print while being conscious of their difference.
The printing system using the new WPF prepares a system which converts GDI printing requested by a Win32 application into XPS printing, and a system which converts XPS printing requested by a WPF application into GDI printing. The print process can be automatically converted between the GDI and the XPS while no application is aware of this. This system allows an application developer (ISV: Independent Software Vendor) to print without being aware of whether the printer driver is a GDI or XPSDrv printer driver. This system also allows a printer driver developer (IHV: Independent Hardware Vendor) to maintain compatibility and user friendliness without preparing a GDI printer driver and XPSDrv printer driver for one printer.
However, the EMF format of the GDI and the XPS format of the WPF have different expressible ranges, so no graphics data can be completely converted between the GDI and the WPF.
Converting EMF into XPS omits graphics data by a raster operation (ROP). The ROP is rendering based on logical operation to combine three bits: a source (S) bit, a destination (D) bit, and a brush pattern (P) bit at this time before transferring a bitmap image, and determine resultant bits from the bit combination.
The ROP is used to superpose two images and make the background transparent, and is employed mainly by a Win32 application which performs presentations and image processes. The GDI renders an image by the ROP, while the WPF does not support any rendering (graphics) method based on logical operation though it has a function OpacityMask capable of designating transparency. Converting EMF data into XPS data may lose an ROP graphics image, and the user may not obtain an output result created using a Win32 application.
Converting XPS data into EMF data may omit an advanced graphics process not supported by the GDI. For example, the XPS can render the ends of a stroke path (line) with different displays (e.g., a semicircle for one end and a triangle for the other end). However, the GDI must render the two line ends with the same display and convert entire data into bitmap data.
After conversion into bitmap data, the GDI printer driver cannot recognize that rendering targets a stroke path, and may not convert print data of a printer control language into optimum data. Further, when the GDI printer driver changes the layout by scaling or the like, bitmapping enlargement jags a line edge. Although a command process can prevent degradation of the image quality, scaling may degrade the quality of the output result in processing bitmap data.
It is desirable to print without the mediacy of the system which converts GDI into XPS or XPS into GDI, but the operating system automatically converts them. To avoid the conversion, the user must determine which of the GDI and XPS attributes the application and printer driver have. In the first place, few users recognize this conversion problem, and it may fail to easily prevent the degradation of the quality of the output result or the degradation of the print quality.
A converter from GDI into XPS or from XPS into GDI is provided as a built-in part of the operating system, and no conversion logic can be externally changed. Even if the printer and printer driver are changed and further an application is changed against omission of rendering, the above-described problem may occur as long as conversion from GDI into XPS or from XPS to GDI is executed.
Print settings has print setting data in a data structure called the DEVMODE structure on the GDI print path, but has it in an XML data structure called PrintTicket on the XPS print path. Conversion from GDI into XPS or from XPS into GDI requires conversion from DEVMODE into PrintTicket or from PrintTicket into DEVMODE. Similar to graphics data, DEVMODE and PrintTicket have different expressible ranges. This process is done not automatically by the operating system but by the printer driver itself using an extended architecture. This process does not omit any data, unlike rendering, if an IHV which creates a printer driver appropriately prepares a conversion process.